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Abstract 


For cases where location servers have access to emergency routing 
information, they are able to return routing information with the 
location information if the location request includes a request for 
the desired routing information. This document specifies an 
extension to the HTTP-Enabled Location Delivery (HELD) protocol that 
updates RFC 5985 to support this function. Allowing location and 
routing information to be acquired in a single request response 
exchange updates RFC 6881, as current location acquisition and route 
determination procedures are separate operations. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7840. 
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Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The general Emergency Context Resolution with Internet Technology 
(ECRIT) calling models described in [RFC6443] and [RFC6881] require a 
local Location-to-Service Translation (LoST) server or network of 
forest guides in order to determine the address of the Public Safety 
Answering Point (PSAP) in the best position to handle a call. 
Networks of forest guides have not materialized and while PSAPs are 
moving towards IP networks, LoST server deployment is not ubiquitous. 
Some regions and countries have expressed reluctance to deploy LoST 
servers making aspects of the current ECRIT architecture hard to 
realize. 


To address regulatory requirements, such as [M493], evolving 
architectures in Europe couple location and routing information in 
the access network while using a softswitch-centric approach to 
emergency call processing. This document describes an extension to 
the HELD protocol [RFC5985], so that a location information server 
can provide emergency routing information in the absence of a LoST 
server or network of forest guides. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


The terms "Location Information Server (LIS)", "Emergency Services 
Routing Proxy (ESRP)", "Voice Service Provider (VSP)", and "Public 
Safety Answering Point (PSAP)" are used as defined in [RFC6443]. 


The term "Access Network Provider" is used as defined in [RFC5687] 
and encompasses both the Internet Access Provider (IAP) and Internet 
Service Provider (ISP). 


The term "forest guide" is used as defined in [RFC5582]. 
3. Motivation 


The Internet emergency calling architecture specified in [RFC6881] 
describes two main models for emergency call processing. The first 
is a device-centric model, where a device obtains location 
information using a location configuration protocol, such as HELD 
[RFC5985], and then proceeds to determine the address of the next hop 
closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this 
model in a simplified form. 
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+---Location Request---+ 


| (1) | 
+++ +---V---+ 
| |<--Location--| LIS | 
| Caller | (2) +------- + + + 
| | ESRP/ 
| |----Find Service------- + | PSAP | 
+------ + (3) | 4 + 
| 4+-------- V----+ 2 
+----- Service----| LoST Server | | 
| (4) +------------- + 4+---+---+ 
HS SERRA Call Initiation------------ >| VSP | 
(5) meer + 


Figure 1: Device-Centric Emergency Services Model 


The second approach is a softswitch-centric model, where a device 
initiates an emergency call, and the serving softswitch detects that 
the call is an emergency and initiates retrieving the caller’s 
location from a LIS using HELD [RFC5985] with identity extensions 
[RFC6155] [RFC6915] and then determines the route to the local PSAP 
using LoST [RFC5222]. Figure 2 shows the high-level protocol 
interactions. 


+---Location Request---+ 


| (2) | 
+---V---+ | 
| Ets | | 
+++ +++ 
| | | 
+----Location--->| Soft- | 
+-------- + (3) | switch | 
Caller |------ Call Initiation------------ > | 
4+-------- + (1) +-+-^---+-+ 
po , NN 
| LoST Server |<-Find Service--+ | | 
+------ 4 - + (4) | | 
|] 
+---------- Service-------- + | 
(5) 
4+----------- + 
ESRP/PSAP |<------ Call----+ 
lc a + (6) 


Figure 2: Softswitch-Centric Calling Model 
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In the softswitch-centric model, when a VSP receives an emergency 
call, it performs two tasks. The first task is to determine the 
correct LIS to ask for location information; this is done using a 
combination of reverse DNS lookup described in [RFC7216] to acquire 
the serving domain name and then using [RFC5986] to determine the LIS 
URI. Once the location is obtained from the LIS, the VSP determines 
the LoST server associated with the domain serving the caller and 
queries it for the correct PSAP address. 


LoST server discovery is a domain-based activity, similar to the LIS 
discovery technique. However, unlike the LIS that is a domain-bound 
service, a LoST server is a geographically bound service. This means 
that for a domain that spans multiple geographic regions, the LoST 
server determined may not be able to provide a route to the necessary 
PSAP. When this occurs, the contacted LoST server invokes the help 
of other LoST servers, and this requires the deployment of forest 
guides. 


At the time of writing, several countries have expressed a reluctance 
to deploy public LoST servers. In countries amenable to the use of 
LoST and forest guides, no public forest guides have been deployed. 
There appears to be little interest from the public sector in 
establishing a global forest-guide network. These issues pose 
threats to the ability of both the device-centric and the softswitch- 
centric calling approaches to operate everywhere. 


The device-centric and softswitch-centric calling models both involve 
the notion of a LIS bound to the serving access network. In many 
cases, the LIS already knows the destination PSAP URI for any given 
location. In [RFC6881], for example, the LIS validates civic 
locations using a location validation procedure based on the LoST 
protocol [RFC5222]. The LoST validation request is similar to a LoST 
routing request and provides the LIS with the same PSAP routing 
information that a routing request would. In other cases, the LIS 
knows the correct PSAP for a given location at provisioning time, or 
the access network might always route to the same emergency provider. 
Irrespective of the way in which the LIS learns the PSAP URI for a 
location, the LIS will, in a great many cases, already have this 
information. 


This document specifies an extension to the HELD protocol, so that 
emergency routing information can be requested from the LIS at the 
same time that location information is requested. This document 
updates [RFC6881] by requiring devices and softswitches that 
understand this specification to always request routing information 
to avoid the risk of query failure where no LoST server or forest- 
guide network is deployed. 
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3.1. LoST Reuse Considerations 


The LoST protocol [RFC5222] defines a <mapping> element that 
describes a service region and associated service URLs. Reusing this 
element from LoST to provide the routing URIS was considered. 
However, this would have meant that several of the mandatory 
components in the <mapping> element would have had to contain 
ambiguous or misleading values. Specifically, the "source" attribute 
is required to contain a LoST application-unique string for the 
authoritative server. However, in the situations described in this 
specification, there may not be an authoritative LoST server, so any 
value put into this attribute would be misleading. In addition to 
this, routing information received in the manner described in this 
specification should not be cached by the receiver, so detailing when 
the routing information expires or was last updated is irrelevant. 


4. Mechanism 


The mechanism consists of adding an element to the HELD 
locationRequest and an element to the locationResponse. 


The request element indicates that the requestor wants the LIS to 
provide routing information based on the location of the end device. 
If the routing request is sent with no attribute, then URIs for 
urn:service:sos are returned. If the requestor wants routing 
information for a specific service, then they may include an optional 
service URN. This service MUST exist in the IANA "Service URN 
Labels" repository created by [RFC5031]. If a service is specified, 
and the LIS does not understand the requested service, then URIs for 
urn:service:sos are returned. 


If the LIS understands the routing request and has routing 
information for the location, then it includes the information ina 
routingInformation element returned in the locationResponse. How the 
LIS obtains this information is left to implementation. 

Possibilities are described in Section 3. 


A LIS that does not understand the routing request element ignores it 
and returns the location information in the normal manner. 


A LIS that does support the routing request element MUST support 
returning URIs for urn:service:sos and any regionally defined sub- 
services while following the URN traversal rules defined in 
[RFC5031]. 
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A LIS that does understand the routing request element but can’t 
obtain any routing information for the end-device’s location MUST set 
the defaultRoute attribute to "true" and return a default PSAP or 
gateway URI along with the determined location information in the 
locationResponse. 


A LIS that understands the routing request element but not the 
specified service URN MUST follow the URN traversal rules defined in 
[RFC5031]. 


A LIS that receives a request for emergency routing information that 
it understands MUST return the correct emergency routing information 
if it has or is able to acquire the routing information for the 
location of the target device. 


The routing information in the location response consists of a 
service element identified by a service name. The service name is a 
URN and might contain a general emergency service URN such as 
urn:service:sos or a specific service URN depending on what was 
requested and what the LIS is able to provide. A list of one or more 


service destinations is provided for the service name. Each 
destination is expressed as a URI, and each URI scheme should only 
appear once in this list. The routing URIs are intended to be used 


at the time they are received. To avoid any risks of using stale 
routing URIs, the values MUST NOT be cached by the receiving entity. 


5. Modification to Phone BCP 
This section describes the normative updates to Phone BCP [RFC6881]. 


It is important for devices and intermediaries to take all steps 
possible to ensure that emergency calls are routed to the correct 
PSAP. An alternative to providing routing information via global 
forest guides or local LoST servers is for local networks to 
configure the PSAP address information in the network location 
server. This specification updates Phone BCP [RFC6881] to provide 
this option. The update requires devices and intermediaries using 
the HELD protocol to always include the HELD routing extension. If 
the LIS is configured with the routing information, it can provide 
it; if it is not, then the device or intermediary tries LoST to 
acquire the PSAP URI. 


Section 6.5 of [RFC6881] defines "End System Location Configuration". 
Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the 
Location Configuration Protocol (LCP) such that "the request MUST 
include the requestRoutingInformation element." The remainder of the 
requirement remains unchanged. 
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This document adds a new requirement to Section 7 of [RFC6881]. 


"ED-5la : Endpoints MUST support the HELD requestRoutingInformation 
element and be able to interpret and use any routing information 
returned in the locationResponse." 


This document adds two new requirements to Section 8 of [RFC6881]. 


"ED-52a : Endpoints that acquire routing information in a HELD 
locationResponse SHOULD use this routing information but MAY perform 
a LoST findService request if they have a location value." 


"ED-52b : Endpoints that acquire routing information in a HELD 
locationResponse with a defaultRoute attribute of "true" MUST perform 
a LoST findService request if they have a location value. If a route 
is provided by the LoST server, then this route MUST be used, 
otherwise the routing information provided in the HELD response 
SHOULD be used." 


This document amends SP-26 from Section 8 of [RFC6881] such that a 
LoST mapping need not be requested if non-default routing information 
is provided in the HELD locationResponse. 


6. HELD Schema Extension 
This section describes the schema extension to HELD. 


<?xml version="1.0"?> 

<xs:schema 
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri" 
xmlns:xml="http://www.w3.org/XML/1998/namespace" 
elementFormDefault="qualified" attributeFormDefault="unqualified"> 


<xs:element name="requestRoutingInformation"> 
<xs:complexType name="empty"> 
<xs:attribute name="service" type="xs:anyUri" 
use="optional" default="urn:service:sos"/> 
</xs:complexType> 
</xs:element> 


<xs:complexType name="service"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
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<xs:sequence> 
<xs:element name="dest" type="xs:anyURI" 
maxOccurs="unbounded"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="defaultRoute" type="xs:boolean" 
use="optional" default="false"/> 
<xs:attribute name="serviceUri" type="xs:anyURI" 
use="required"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 


<xs:element name="routingInformation" type="ri:riType"/> 


<xs:complexType name="riType"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
<xs:sequence> 
<xs:element name="service" type="ri:service"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 


</xs:schema> 
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7. Examples 


Figure 3 illustrates a <locationRequest> example that contains IP 
flow information in the request. 


<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" 
responseTime="emergencyRouting"> 


<requestRoutingInformation 
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/> 


<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow" 
layer4="tcp" layer3="ipv4"> 
<src> 
<address>192.0.2.12</address> 
<port>1024</port> 
</src> 
<dst> 
<address>192.0.2.195</address> 
<port>80</port> 
</dst> 
</flow> 
</locationRequest> 


Figure 3: Example Location Request 
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Figure 4 illustrates the <locationResponse> message containing two 
location URIs: an HTTPS and a SIP URI. Additionally, the response 
contains routing information. 


<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> 
<locationUriSet expires="2006-01-01T13:00:00.02"> 
<locationURI> 
https://ls.example.com: 9768/357yc6s64ceyoiuy5ax3o0 
</locationURI> 
<locationURI> 
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 
</locationURI> 
</locationUriSet> 


<routingInformation 
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"> 
<service serviceUri="urn:service:sos"> 
<dest>sip:112@example.com</dest> 
<dest>sips:112@example.com</dest> 
<dest>xmpp:112@example.com</dest> 
</service> 
</routingInformation> 


</locationResponse> 


Figure 4: Example Location Response 


Winterbottom, et al. Standards Track [Page 11] 


RFC 7840 HELD Routing May 2016 


Figure 5 illustrates the <locationResponse> message containing 
default routing information and an HTTPS location URI. 


<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> 
<locationUriSet expires="2016-01-01T13:00:00.02"> 
<locationURI> 
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 
</locationURI> 
</locationUriSet> 


<routingInformation 
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"> 
<service defaultRoute="true" serviceUri="urn:service:sos"> 
<dest>sip:112@example.com</dest> 
<dest>sips:112@example.com</dest> 
<dest>xmpp:112@example.com</dest> 
</service> 
</routingInformation> 


</locationResponse> 


Figure 5: Example Location Response with Default Routing Information 


8. Privacy Considerations 


This document makes no changes that require privacy considerations 
beyond those already described in [RFC5985]. It does, however, 
extend those described in [RFC6155]. 


[RFC5985] describes the privacy considerations surrounding the HELD 


location configuration protocol, and this document makes no specific 


changes to these considerations. 


[RFC6155] extends HELD beyond a simple LCP by enabling authorized 
third parties to acquire location information and describing the 
issues in Section 4. The HELD routing extension supports returning 
URIs that represent specific services operating in the Target’s 
vicinity. This represents additional information about the Target; 
as a consequence, it is recommended that this option only be used 
when the LIS returns a location URI, not a location value. 


9. Security Considerations 


This document imposes no additional security considerations beyond 
those already described in [RFC5985] and [RFC6155]. 
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10. IANA Considerations 


10.1. URN Sub-Namespace Registration for 
‘urn:ietf:params:xml:ns:geopriv:held:ri’ 


Per this document, IANA has registered a new XML namespace, following 
the guidelines in [RFC3688]. 


URI: urn:ietf:params:xml:ns:geopriv:held:ri 


Registrant Contact: IETF ECRIT working group (ecrit@ietf.org), 
James Winterbottom (a.james.winterbottom@gmail.com). 


XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtmll-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> 
<head> 
<title>HELD Routing Information Extensions</title> 
</head> 
<body> 
<hl>Additional Element for HELD Routing Information</hl> 
<h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7840.txt"> 
RFC 7840</a>.</p> 
</body> 
</html> 
END 


10.2. XML Schema Registration 


This section registers an XML schema as per the procedures in 
[RFC3688]. 


URI: urn:ietf:params:xml:schema:geopriv:held:ri 


Registrant Contact: IETF ECRIT working group (ecrit@ietf.org), 
James Winterbottom (a.james.winterbottom@gmail.com). 


XML: The XML for this schema can be found as the entirety of 
Section 6 of this document. 
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